System and method for generating a finance attribute from tradeline data

ABSTRACT

Embodiments of a system and method are described for generating a finance attribute. In one embodiment, the systems and methods retrieve raw tradeline data from a plurality of credit bureaus, retrieve industry code data related to each of the plurality of credit bureaus, determine one or more tradeline leveling characteristics that meet at least one pre-determined threshold, and generate a finance attribute using the selected leveling characteristics.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/253,776, filed Oct. 5, 2011, which is a continuation of U.S.application Ser. No. 11/973,300, filed Oct. 5, 2007, issued as U.S. Pat.No. 8,036,979, which is based upon and claims the benefit of priorityfrom U.S. Provisional Application No. 60/849,542, filed on Oct. 5, 2006,the entire contents of which are all incorporated herein by reference intheir entireties. All publications and patent applications mentioned inthis specification are herein incorporated by reference in theirentirety to the same extent as if each individual publication or patentapplication was specifically and individually indicated to beincorporated by reference.

TECHNICAL FIELD

This disclosure generally relates to financial data processing, and moreparticularly to improved methods and systems for creating a financialattribute from data stored in credit databases.

DESCRIPTION OF RELATED ART

Various financial service providers provide credit accounts such asmortgages, automobile loans, credit card accounts, and the like, toconsumers and businesses. In determining whether to extend credit to anapplicant and under what terms, the financial service providers may relyupon financial data related to the credit activities, current assets,and current liabilities of the applicant. This information may beprovided in the form of a credit score or with a credit report. A creditreport may present the financial history of the credit applicant.

SUMMARY OF DISCLOSURE

In some embodiments, a system is described to provide additionalrelevant information to a financial service provider or other entity toallow that provider to make more informed decisions. One statisticalrisk tool used by financial service providers to predict paymentbehavior is a scorecard, and many scorecards rely on attributesgenerated from financial tradeline data from multiple credit datasources, for example, multiple credit bureaus. The attributes and/orscorecards provide more accessible and aggregated representations of thetradeline data and enable financial service providers to quicklydetermine the credit-worthiness of a credit applicant.

In certain cases, each credit bureau or other entity stores and reportsfinancial tradeline data in a different format. Accordingly, attributeaggregation instructions can be developed for each bureau. The differentdata formats create significant challenges to the creation of attributesacross the multiple bureaus.

According to one embodiment, the system generates a finance attributefrom tradeline data obtained from multiple credit data sources. In oneembodiment, the generated attribute can be used as a stand aloneattribute to evaluate the financial behavior the credit applicant. Inanother embodiment, the attribute is used as part of a larger scorecardanalysis to determine the payment default risk of a credit applicant.

Accordingly, embodiments of a system and method are described forgenerating a finance attribute from raw financial tradeline datareported by multiple credit data sources. In one embodiment, a computerimplemented method for generating a finance attribute from raw tradelinedata from a plurality of credit bureaus is provided. The method maycomprise retrieving raw tradeline data from each of the plurality ofcredit bureaus; retrieving industry code data related to each of theplurality of credit bureaus; determining one or more tradeline levelingcharacteristics that meet at least one predetermined threshold; andgenerating a finance attribute using the selected levelingcharacteristics.

In another embodiment, determining one or more tradeline levelingcharacteristics that meet at least one pre-determined thresholdscomprises designating a plurality of lowest common denominators from theindustry code data related to each of the plurality of credit bureaus asthe selected leveling characteristics; leveling the raw tradeline datafrom each of the plurality of credit bureaus to generate leveledtradeline data using the selected leveling characteristics; excludingextraneous tradeline data from the leveled tradeline data; measuring acorrelation among the leveled tradeline data and the raw tradeline data;determining whether the correlation meets the at least one pre-definedthreshold; adjusting the selected leveling characteristics if thecorrelation fails to meet the at least one pre-defined thresholdcomprising at least one of narrowing the selected levelingcharacteristics for at least one of the credit bureaus to a differentsubset of industry code data or including additional industry code datafor at least one of the credit bureaus not included in the lowest commondenominators in the selected leveling characteristics; and repeatingsaid leveling, excluding, measuring, determining, and adjusting untilthe selected leveling characteristics generate a correlation that meetsthe at least one pre-defined threshold.

In another embodiment, determining one or more tradeline levelingcharacteristics that meet one or more pre-determined thresholdscomprises designating a plurality of lowest common denominators from theindustry code data related to each of the plurality of credit bureaus asthe selected leveling characteristics; leveling the raw tradeline datafrom each of the plurality of credit bureaus to generate leveledtradeline data using the selected leveling characteristics; measuring acorrelation among the leveled tradeline data and the raw tradeline data;determining whether the correlation meets the at least one pre-definedthreshold; adjusting the selected leveling characteristics if thecorrelation fails to meet the at least one pre-defined thresholdcomprising at least one of narrowing the selected levelingcharacteristics for at least one of the credit bureaus to a differentsubset of industry code data or including additional industry code datafor at least one of the credit bureaus not included in the lowest commondenominators in the selected leveling characteristics; and repeatingsaid leveling, measuring, determining, and adjusting until the selectedleveling characteristics generate a correlation that meets the at leastone pre-defined threshold.

In another embodiment, a computing system is provided. The computingsystem may comprise a communications module configured to receive rawtradeline data related to a plurality of credit bureaus and to receiveindustry code data related to each of the plurality of credit bureaus; afinance attribute generation module configured to receive raw tradelinedata from each of the plurality of credit bureaus via the communicationsmodule, receive industry code data related to each of the plurality ofcredit bureaus; determine one or more tradeline leveling characteristicsthat meet at least one pre-determined threshold, and generate a financeattribute using the selected leveling characteristics; and a processormodule configured to execute the finance attribute generation module.

In a further embodiment, the finance attribute generation module of thecomputing system is further configured to determine one or moretradeline leveling characteristics that meet at least one pre-determinedthresholds by designating a plurality of lowest common denominators fromthe industry code data related to each of the plurality of creditbureaus as the selected leveling characteristics; leveling the rawtradeline data from each of the plurality of credit bureaus to generateleveled tradeline data using the selected leveling characteristics;excluding extraneous tradeline data from the leveled tradeline data;measuring a correlation among the leveled tradeline data and the rawtradeline data; determining whether the correlation meets the at leastone pre-defined threshold; adjusting the selected levelingcharacteristics if the correlation fails to meet the at least onepre-defined threshold comprising at least one of narrowing the selectedleveling characteristics for at least one of the credit bureaus to adifferent subset of industry code data or including additional industrycode data for at least one of the credit bureaus not included in thelowest common denominators in the selected leveling characteristics; andrepeating said leveling, excluding, measuring, determining, andadjusting until the selected leveling characteristics generate acorrelation that meets the at least one pre-defined threshold.

In a further embodiment, the finance attribute generation module of thecomputing system is further configured to determine one or moretradeline leveling characteristics that meet at least one pre-determinedthresholds by designating a plurality of lowest common denominators fromthe industry code data related to each of the plurality of creditbureaus as the selected leveling characteristics; leveling the rawtradeline data from each of the plurality of credit bureaus to generateleveled tradeline data using the selected leveling characteristics;measuring a correlation among the leveled tradeline data and the rawtradeline data; determining whether the correlation meets the at leastone pre-defined threshold; adjusting the selected levelingcharacteristics if the correlation fails to meet the at least onepre-defined threshold comprising at least one of narrowing the selectedleveling characteristics for at least one of the credit bureaus to adifferent subset of industry code data or including additional industrycode data for at least one of the credit bureaus not included in thelowest common denominators in the selected leveling characteristics; andrepeating said leveling, measuring, determining, and adjusting until theselected leveling characteristics generate a correlation that meets theat least one pre-defined threshold.

For purposes of summarizing the invention, certain aspects, advantagesand novel features of the invention have been described herein. Ofcourse, it is to be understood that not necessarily all such aspects,advantages or features will be embodied in any particular embodiment ofthe invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system for generating a finance attributeaccording to one embodiment;

FIG. 2 shows example tradeline data as reported by different bureausaccording to one embodiment;

FIG. 3 shows example data structures used by different credit datasources according to one embodiment;

FIG. 4 is a flow chart showing the process of generating a financeattribute according to one embodiment;

FIG. 5 is a flow chart showing a process for determining characteristicsfor leveling according to one embodiment;

FIG. 6 shows a set of characteristics for leveling and the accompanyingresults on a sample data set according to one embodiment;

FIG. 7 shows another set of characteristics for leveling and theaccompanying results on a sample data set according to one embodiment;

FIG. 8 shows yet another set of characteristics for leveling and theaccompanying results on a sample data set according to one embodiment;

FIG. 9 shows a set of characteristics for leveling and the accompanyingresults on a sample data set according to one embodiment;

FIGS. 10A-10E show the results of applying various characteristics forleveling on a sample data set according to one embodiment;

FIG. 11 provides a comparison between the results of using two differentsets of characteristics for leveling according to one embodiment;

FIGS. 12A-C provide comparison between the results of using twodifferent sets of characteristics for leveling for three credit datasources according to one embodiment; and

FIG. 13 shows the results of two financial models that use financeattributes generated by a set of characteristics for leveling accordingto one embodiment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Embodiments of the invention will now be described with reference to theaccompanying figures, wherein like numerals refer to like elementsthroughout. The terminology used in the description presented herein isnot intended to be interpreted in any limited or restrictive manner,simply because it is being utilized in conjunction with a detaileddescription of certain specific embodiments of the invention.Furthermore, embodiments of the invention may include several novelfeatures, no single one of which is solely responsible for its desirableattributes or which is essential to practicing the inventions hereindescribed.

FIG. 1 is one embodiment of a block diagram of a computing system 100that is in communication with a network 160 and various systems that arealso in communication with the network 160. The computing system 100 maybe used to implement certain systems and methods described herein. Forexample, the computing system 100 may be configured to receive financialand demographic information regarding individuals and generate reportsand/or alerts for one or more clients. Although the description providedherein refers to individuals, consumers, or customers, the terms“individual,” “consumer,” and “customer” should be interpreted toinclude applicants, or groups of individuals or customers or applicants,such as, for example, married couples or domestic partners,organizations, groups, and business entities.

The computing system 100 includes, for example, a personal computer thatis IBM, Macintosh, or Linux/Unix compatible. In one embodiment, thecomputing system 100 comprises a server, a laptop computer, a cellphone, a personal digital assistant, a kiosk, or an audio player, forexample. In one embodiment, the exemplary computing system 100 includesa central processing unit (“CPU”) 105, which may include a conventionalmicroprocessor. The computing system 100 further includes a memory 130,such as random access memory (“RAM”) for temporary storage ofinformation and a read only memory (“ROM”) for permanent storage ofinformation, and a mass storage device 120, such as a hard drive,diskette, or optical media storage device. Typically, the modules of thecomputing system 100 are connected to the computer using a standardsbased bus system. In different embodiments, the standards based bussystem could be Peripheral Component Interconnect (“PCP”), Microchannel,Small Computer System Interface (“SCSI”), Industrial StandardArchitecture (“ISA”) and Extended ISA (“EISA”) architectures, forexample. In addition, the functionality provided for in the componentsand modules of computing system 100 may be combined into fewercomponents and modules or further separated into additional componentsand modules.

The computing system 100 is generally controlled and coordinated byoperating system software, such as Windows 95, Windows 98, Windows NT,Windows 2000, Windows XP, Windows Vista, Linux, SunOS, Solaris, or othercompatible operating systems. In Macintosh systems, the operating systemmay be any available operating system, such as MAC OS X. In otherembodiments, the computing system 100 may be controlled by a proprietaryoperating system. Conventional operating systems control and schedulecomputer processes for execution, perform memory management, providefile system, networking, I/O services, and provide a user interface,such as a graphical user interface (“GUI”), among other things.

The exemplary computing system 100 includes one or more commonlyavailable input/output (I/O) devices and interfaces 110, such as akeyboard, mouse, touchpad, and printer. In one embodiment, the I/Odevices and interfaces 110 include one or more display device, such as amonitor, that allows the visual presentation of data to a user. Moreparticularly, a display device provides for the presentation of GUIs,application software data, and multimedia presentations, for example.The computing system 100 may also include one or more multimedia devices140, such as speakers, video cards, graphics accelerators, andmicrophones, for example.

In the embodiment of FIG. 1, the I/O devices and interfaces 110 providea communication interface to various external devices. In the embodimentof FIG. 1, the computing system 100 is electronically coupled to anetwork 160, which comprises one or more of a LAN, WAN, or the Internet,for example, via a wired, wireless, or combination of wired andwireless, communication link 115. The network 160 communicates withvarious computing devices and/or other electronic devices via wired orwireless communication links.

According to FIG. 1, information is provided to computing system 100over the network 160 from one or more data sources including, forexample, credit databases 162. The information supplied by the variousdata sources may include credit data, demographic data, applicationinformation, product terms, accounts receivable data, and financialstatements, for example. In addition to the devices that are illustratedin FIG. 1, the network 160 may communicate with other data sources orother computing devices. In addition, the data sources may include oneor more internal and/or external data sources. In some embodiments, oneor more of the databases or data sources may be implemented using arelational database, such as Sybase, Oracle, CodeBase and Microsoft® SQLServer as well as other types of databases such as, for example, a flatfile database, an entity-relationship database, and object-orienteddatabase, and/or a record-based database.

In addition to supplying data, client 164 may further requestinformation from the computing system 100. For example, the client 164may request data related to a consumer or a group of consumers. Such arequest may include consumer information identifying the consumer(s) forwhich information is desired.

The I/O devices and interfaces 110 further provide a communicationinterface to an internal credit database 172. In the embodiment of FIG.1, the computing system 100 is coupled to a secured network 161, such asa secured LAN, for example. The secured network 161 communicates withthe internal credit database 172. In some embodiments, the internalcredit database 172 is configured to communicate with additionalcomputing devices over the network 160 or some other network, such as aLAN, WAN, or the Internet via a wired, wireless, or combination of wiredand wireless, communication link. In certain embodiments, the client 164may have access to the internal credit database 172 through the network160, and/or the secured network 161.

In the embodiment of FIG. 1, the computing system 100 also includes afinance attribute generation module 150 that may be executed by the CPU105. This module may include, by way of example, components, such assoftware components, object-oriented software components, classcomponents and task components, processes, functions, attributes,procedures, subroutines, segments of program code, drivers, firmware,microcode, circuitry, data, databases, data structures, tables, arrays,and variables.

In the embodiment shown in FIG. 1, the computing system 100 isconfigured to execute the finance attribute generation module 150, amongothers, in order to generate and/or calculate the value for a financeattribute. Finance attribute generation module 150 is further configuredto access internal credit database 172, credit databases 162, along withadditional sources of information. In some embodiments, financeattribute generation module 150 may be configured to obtain tradelinedata from internal credit database 172, from credit databases 162 orfrom a combination of internal credit database 172 and credit databases162. These records are accessed by the finance attribute generationmodule 150 to generate a finance attribute aggregated from raw tradelinedata returned by the various credit databases, as will be described inmore detail below.

In general, the word “module,” as used herein, refers to logic embodiedin hardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programminglanguage, such as, for example, Java, Lua, C or C++. A software modulemay be compiled and linked into an executable program, installed in adynamic link library, or may be written in an interpreted programminglanguage such as, for example, BASIC, Perl, or Python. It will beappreciated that software modules may be callable from other modules orfrom themselves, and/or may be invoked in response to detected events orinterrupts. Software instructions may be embedded in firmware, such asan EPROM. It will be further appreciated that hardware modules may becomprised of connected logic units, such as gates and flip-flops, and/ormay be comprised of programmable units, such as programmable gate arraysor processors. The modules described herein are preferably implementedas software modules, but may be represented in hardware or firmware.Generally, the modules described herein refer to logical modules thatmay be combined with other modules or divided into sub-modules despitetheir physical organization or storage.

FIG. 2 shows examples of finance tradeline data as reported by threedifferent credit data sources. In the example, the credit data sourcesare credit bureaus, though in other embodiments, the credit data sourcesare other sources in addition or instead of one or more of the creditbureaus. Tradeline data 200, 202, and 204 are from various credit datasources, for example, from credit bureau 1, credit bureau 2, and creditbureau 3, respectively. These could be, for example, Experian, Equifax,and TransUnion. Although all three examples refer to the same tradelineof the individual consumer profiled, a “NORTHEAST CREDIT UNION” account,each bureau reports that tradeline data differently. The differencesarise from the mechanism(s) by which credit data are collected andstored. For example, in the United States, even though creditors reportdata to the credit data sources in standard Metro formats, each datasource interprets the information differently and has its own uniqueformat for returning the data.

In some embodiments, the tradeline data may comprise different oradditional data fields than as shown. A skilled artisan will understandthat the processes described herein may be modified to accommodatedifferent forms of financial data.

FIG. 3 shows a particular example of how the data and/or data structuresmay vary across the credit data sources. In this example, although bothcredit data sources 300 and 302 use two-letter codes to denote thetradeline category, they differ in their internal coding. For example,credit data source 300 has additional codes to denote tradeline relatedto education loans (those beginning with “E”). On the other hand, somecredit data sources such as credit data source 304 may use a one-lettercode to denote the tradeline category (for example using “F” to denoteall tradelines related to personal finance).

Aside from the differences in data and/or data structures, there arealso variations in data representation. As a result, the same loan bythe same consumer may be represented differently across different creditdata sources. For example, credit data source 300 may classify an autoloan tradeline with the code “FA” (for Auto financing co.) while creditdata source 302 may classify the same loan as “FP” (for Personal loanco.). Credit data source 304 may simply classify the same loan with an“F” code (generic Personal Finance). Thus, a creditor who relies on suchdata to determine whether to extend credit needs to account for thesedifferences. In many instances, these differences make this a difficultendeavor for the average creditor. The finance attributes generated byembodiments of the disclosure take these differences into account andenable such a creditor to easily and quickly assess consumer behavior.

FIG. 4 is a system flowchart showing the operation of embodiments of thedisclosure that may be executed on computing system 100. The operationbegins at state 402, where raw tradeline data is first retrieved and/orreceived. Industry code data from the various credit data sources, suchas those illustrated in FIG. 3, is then retrieved and/or received instate 404. Next, at state 406 tradeline characteristics, such as thoseshown in FIG. 6, are determined. Then at state 408, a finance attributeis generated using the selected characteristics. It is recognized thatother embodiments of FIG. 4 may also be used, such as, for example,embodiments where the raw tradeline data is retrieved and/or receivedafter or at the same time as the industry code data, and embodimentswhere raw tradeline data is retrieved and/or received and industry codedata is not retrieved and/or received. While this example focuses onfiltering finance tradeline data, those skilled in the art willappreciate that the same leveling methods can be applied to varioustypes of credit or financial data.

The process of leveling involves determining a proper set ofcharacteristics that will yield leveled, for example, consistenttradeline data from the various credit data sources. As can be seen inFIG. 6 below, once the KOB or Industry code data are known, the goalbecomes incorporating the proper codes into the set of characteristics.Embodiments of the present disclosure use an iterative process to selectcharacteristics and measure the resulting data against certainthresholds, with each successive iteration producing more refinedcharacteristics that produces more leveled data.

FIG. 5 illustrates one embodiment of the process undertaken in state 406of FIG. 4 according to one embodiment. The process begins in state 502,where a plurality of lowest common denominators is designated as theselected characteristics to be used in the leveling. In one embodiment,the lowest common denominators selected are the minimum set ofoverlapping tradeline category codes. Then in state 504, the rawtradeline data are leveled using the selected characteristics. Next, instate 506, extraneous tradeline data are excluded from the leveledtradeline data. In another embodiment, the process moves to state 508without excluding the extraneous tradeline data. In state 508, theprocess measures a correlation among the leveled tradeline data and theraw tradeline data. At decision state 510, if the correlation measuredin 508 meets one or more pre-defined thresholds, the process iscomplete, exits this process, and proceeds, for example, to state 408 ofFIG. 4, where a finance attribute is generated. Otherwise, if thecorrelation does not meet the thresholds, the process proceeds to state512, where the selected characteristics for leveling are adjusted andthe process begins again.

In one embodiment, the thresholds differ based on the desired attributeand/or are pre-defined. For example, an embodiment of the invention mayhave a range of acceptable percentages as the thresholds. In thatembodiment, if the differences among leveled tradeline data (such as theones shown in graph 810 as discussed below) are within those ranges,then the thresholds are considered met. In other embodiments, suchthresholds are defined so that the system will undertake a fewer numberof iterations as to produce quicker results. Those skilled in the artcan appreciate that the thresholds can be tailored to a variety ofpotentially competing objectives such as speed and accuracy, so that anumber of trade-offs may be considered before such thresholds are inputinto the system.

FIG. 6 provides an example of different finance attributes from multiplecredit data sources according to an embodiment of the invention.Characteristics 600 comprise various finance characteristics.Characteristics 602 are directed to tradeline data from credit datasource 1. Because credit data source 1 uses a two-letter Kind ofBusiness (KOB) code to categorize its tradeline data, characteristics602 use a set of two-letter finance-related codes to select financetradeline data. Similarly, characteristics 604 are directed to tradelinedata from credit data source 2. Much like characteristics 602,characteristics 604 also use a set of finance-related codes. Finally,characteristics 606 are directed to tradeline data from credit datasource 3, which uses a one-letter Industry code. The term “REV” meansrevolving tradelines and the term “ILN” means installment tradelines. Inthis example, both types of tradelines are selected. The term “STU”means student tradelines and these tradelines are excluded in thisexample.

In FIG. 6, graph 610 shows the results of applying characteristics 600to a sample data set from the three credit data sources. The attributevalue “1+” means one or more tradelines. The graph 610 shows that 77.28%of consumers have at least one finance tradeline in credit data source1, 81.02% of consumers have at least one finance tradeline in creditdata source 2, and 58.01% of consumers have at least one financetradeline in credit data source 3. While there is substantial overlap,the differences reflect the different data structures andrepresentations used by the credit data sources. In this example, thedifferences among the results do not meet a predetermined preferredthreshold. Therefore, in one embodiment, the characteristics are furtherrefined to level the data.

FIG. 7 shows the use of revised characteristics along with the results.Characteristics 700 utilize the lowest common denominators across thecredit data sources. This example embodiment of the invention recognizesthat all three credit data sources use “F” in whole or in part in theircategorization of finance tradeline data. Using this lowest commondenominator approach, characteristics 702 select any tradeline datawithin credit data source 1 that has a KOB code that begins with “F,” asshown by the pseudo-code “F*.” Similarly, characteristics 704 select anytradeline data within credit data source 2 that has an Industry codethat begins with “F,” as shown by the pseudo-code “F*.” Finally,characteristics 706 select any tradeline data with an Industry code “F”within credit data source 3.

Graph 710 shows the results of applying characteristics 700 to the samesample data set as in FIG. 6. The graph 710 shows that characteristics700 results in a 27.98% match from credit data source 1, a 35.88% matchfrom credit data source 2, and a 10.78% match from credit data source 3.In this example, the differences among the results do not meet apredetermined preferred threshold. Accordingly, another leveling attemptis applied.

FIG. 8 shows the use of revised characteristics along with the results.Here, characteristics 800 use a more refined set of characteristics thanthose shown in FIG. 7. This embodiment also recognizes that all threecredit data sources use “F” in whole or in part in their categorizationof finance tradeline data. Therefore, characteristics 802 and 804 selectwith “F*.” In addition, characteristics 806 also select for code “Q”within credit data source 3 to capture those tradeline data categorizedas “Q—other finance.”

Graph 810 shows the results of applying characteristics 800 to the samesample data set as in FIGS. 6 and 7. Characteristics 800 results in a27.98% match from credit data source 1, a 35.88% match from credit datasource 2, and a 12.70% match from credit data source 3, an increase ofabout two percent over bar 716 from graph 710. In this example, thedifferences among the results do not meet a predetermined preferredthreshold. Accordingly, another leveling attempt is applied. By way ofthis iterative process of refining the characteristics, embodiments ofthe present disclosure improve the quality of the resulting financeattributes. In other embodiments, the thresholds can be defined so thatthe results shown in FIG. 6, 7, or 8 would satisfy the thresholds,thereby enabling those embodiments to undertake fewer revisions to thecharacteristics and generate the finance attribute with greater speed.

FIG. 9 shows the use of revised characteristics as well as a cleanup toeliminate extraneous tradelines. Characteristics 900 use a more refinedset of characteristics than those shown in FIG. 8. This embodiment alsorecognizes that focus on the “FP” codes Therefore, characteristics 902select FP, characteristics 904 select FP, and characteristics 906 selectF. In addition, a clean up is applied to the characteristics 900 toremove extraneous tradeline data. For example, in this embodimentcharacteristics 902, 904, and 906 remove ALE, STU, and MTG (auto leasetrades, student trades, mortgage loan trades, etc.).

Graph 910 shows the results of applying characteristic set 900 to thesame sample data set as in FIGS. 6, 7, and 8. The graph 910 shows thatcharacteristics 900 result in a 38.22% match from credit data source 1,a 40.21% match from credit data source 2, and a 51.14% match from creditdata source 3. In this example, the differences among the results domeet the pre-determined preferred threshold so the iterative process canend and the finance attribute can be generated.

One embodiment of a method of measuring correlation is furtherillustrated below in conjunction with FIGS. 10A-10E. FIGS. 10A-10E showthe correlation among the results of applying different characteristicsfor leveling on a sample data set according to one embodiment of thepresent disclosure.

FIG. 10A shows the results of applying a set of characteristics thatfocuses on the KOB or Industry code “FF” (sales financing) at B2, orcredit bureau 2. Graph 1004 shows a 100% match at B2 since thecharacteristics include the same Industry code used by B2. Graph 1002shows the type of data returned by B3, or credit bureau 3, using thesame characteristics. It indicates that 50.44% of the data returned arein the “D” category, 13.64% of the data returned are in the “F”category, and 35.92% of the data returned are in the “Other” category.The “D” category stands for department store accounts. Graph 1006 showsthe type of data returned by B1, or credit bureau 1, using the samecharacteristics. It indicates that 48.37% of the data returned are inthe “DC” category (also stands for department stores), 15.16% of thedata returned are in the “FP” category, 11.39% of the data returned arein the “FF” category, and 25.08% of the data returned are in the “Other”category.

FIG. 10B shows the results of applying a set of characteristics thatfocuses on the KOB or Industry code “FP” (personal finance) at B2. Graph1014 shows a 100% match at B2 since the characteristics include the sameIndustry code used by B2. Graph 1012 shows the type of data returned byB3 using the same characteristics. It indicates that 90.25% of the datareturned are in the “F” (personal finance) category and 9.75% of thedata returned are in the “Other” category. There is a high degree ofcorrelation between the results from B2 and B3. A similar highcorrelation is found between the results from B1 and B2. Graph 1016indicates that 90.60% of the data returned are in the “FP” category,with 9.40% of the data returned are in the “Other” category.

FIG. 10C shows the results of applying a set of characteristics thatfocuses on the KOB or Industry code “FF” at B1. Graph 1026 shows a 100%match at B1 since the characteristics include the same Industry codeused by B1. Graph 1022 shows the type of data returned by B3 using thesame characteristics. It indicates that 17.58% of the data returned arein the “F” category, 59.60% of the data returned are in the “Q”category, and 22.82% of the data returned are in the “Other” category.Graph 1024 shows the type of data returned by B2. It indicates that47.70% of the data returned are in the “FA” (auto financing) category,9.06% of the data returned are in the “FF” category, 20.67% of the datareturned are in the “BB” (banks) category, and 22.57% of the datareturned are in the “Other” category.

FIG. 10D shows the results of applying a set of characteristics thatfocuses on the KOB or Industry code “FP” at B1. Graph 1036 shows a 100%match at B1 since the characteristics include the same Industry codeused by B1. Graph 1032 shows the type of data returned by B3 andindicates that 77.51% of the data returned are in the “F” category,8.62% of the data returned are in the “Q” category, and 13.87% of thedata returned are in the “Other” category. The amounts to a highcorrelation between the data from B3 and B1 because “F” and “Q” datafrom B3 are both finance tradelines and they combine to make up over 86%of the result. Similarly, there is a high correlation between the datafrom B1 and B2. Graph 1034 shows the type of data returned by B2. Itindicates that 6.56% of the data returned are in the “FA” category,9.04% of the data returned are in the “FF” category, 65.70% of the datareturned are in the “FP” category, and 18.70% of the data returned arein the “Other” category. The categories that begin with “F” from B2total again over 80%, which means that 80% of the data returned by B2using the same characteristics are finance tradelines as well.

Finally, FIG. 10E shows the results of applying a set of characteristicsthat focuses on the Industry code “F” at B3, or credit bureau 3. Graph1042 shows a 100% match at B3 since the characteristics include the sameIndustry code used by B3. Graph 1044 shows the type of data returned byB2. It indicates that 9.85% of the data returned are in the “FM”category, 49.27% of the data returned are in the “FP” category, 18.64%of the data returned are in the “FA” category, 8.37% of the datareturned are in the “FF” category, and 13.87% of the data returned arein the “Other” category. Graph 1046 shows the type of data returned byB1. It indicates that 28.16% of the data returned are in the “FA”category, 15.81% of the data returned are in the “FM” category, 41.60%of the data returned are in the “FP” category, and 14.43% of the datareturned are in the “Other” category. Because of the high degree ofcorrelation among the results in FIG. 10B, in one embodiment thosecharacteristics shown in FIG. 10B are used to level tradeline data.Other embodiments use the characteristics shown in FIG. 10A, 10C-10E.Another embodiment evaluates the results of applying thesecharacteristics in an iterative process and selects the ones with thebest correlation as part of state 406 in FIG. 4.

FIG. 11 illustrates embodiments of a side-by-side comparison of theresults shown in FIGS. 6 and 9. Graph 1100 shows the resulting tradelinedata from applying the characteristics shown in FIG. 6, while graph 1110shows the resulting tradeline data from applying the characteristicsshown in FIG. 9. As can be seen, the results from applying thecharacteristics in FIG. 9 have a higher correlation and are moreleveled. One embodiment of the invention may begin by selectingcharacteristics that produce results similar to those shown in FIG. 6,and through the iterative process described above in conjunction withFIGS. 6-9, and/or 10A-E, arrive at characteristics that produce resultssimilar to those shown in FIG. 9.

FIGS. 12A-12C illustrate embodiments of graphs that show the use ofunleveled attributes and leveled attributes as predictors of paymentdefaults for each of the credit bureaus. In FIG. 12A, Graph 1200 showsan example finance attribute generated by an embodiment of the presentdisclosure. The left Y-axis shows the bad-rate, for example, the rate ofdefaults, as indicated by the line graph. The right Y-axis shows thepercent of population that had a finance trade in the past 12 months inthe sample data set, as indicated by the bar graph. The bar graphrepresents the finance attribute. Thus, graph 1200 shows thatapproximately 70% of the population had obtained 0 finance trades (afinance attribute of 0) in the last 12 month, and of those 70%, justover 3% had a default “bad rate.” The “bad rate” rises slightly forthose with 1 finance trade in the last 12 months (a finance attributeof 1) and those with 2 or more trades (a finance attribute of 2+). ThePearson correlation coefficient for graph 1210 is −0.006. Pearsoncorrelation coefficients are used to indicate the strength of a linearrelationship between two variables, which in this example are the badrate and the total number of personal finance trades.

Graph 1210 shows a leveled finance attribute generated by anotherembodiment of the present disclosure. This finance attribute isgenerated by using characteristics that focus on the “FP” code. The “badrate” rises more dramatically for those in the population that have oneor two or more trades. The Pearson correlation coefficient for graph1210 is −0.014, thereby showing a higher correlation between the numberof personal finance trade and the bad rate in the graph 1210 than in thegraph 1200. Therefore, the leveled finance attribute shown in graph 1210demonstrates a greater correlation to credit risk than the non-leveledfinance attribute shown in graph 1200.

FIG. 12B focuses on data obtained from another credit data source,credit bureau 2. Graph 1220 shows that approximately 90% of thepopulation had obtained 0 finance trades (a finance attribute of 0) inthe last 12 months, and of those 90%, just over 3% had a default “badrate.” The “bad rate” rises higher for those with 1 finance trade in thelast 12 months (a finance attribute of 1) and even more for those with 2or more trades (a finance attribute of 2+). The Pearson correlationcoefficient for graph 1220 is −0.020.

Graph 1230 shows a leveled finance attribute where the “bad rate” risesless dramatically for those in the population that have one or two ormore trades. The Pearson correlation coefficient for graph 1230 is−0.014, thereby showing a lower correlation between the number ofpersonal finance trade and the bad rate in the graph 1230 than in thegraph 1220. Therefore, the non-leveled finance attribute shown in graph1220 demonstrates a greater correlation to credit risk than the leveledfinance attribute shown in graph 1230.

FIG. 12C focuses on data obtained from another credit data source,credit bureau 3. Graph 1240 shows that approximately 76% of thepopulation had obtained 0 finance trades (a finance attribute of 0) inthe last 12 months, and of those 76%, just over 3% had a default “badrate.” The “bad rate” rises slightly higher for those with 1 financetrade in the last 12 months (a finance attribute of 1) and slightly morefor those with 2 or more trades (a finance attribute of 2+). The Pearsoncorrelation coefficient for graph 1220 is −0.006.

Graph 1250 shows a leveled finance attribute where the “bad rate” risesdramatically for those in the population that have one or two or moretrades. The Pearson correlation coefficient for graph 1250 is −0.024,thereby showing a higher correlation between the number of personalfinance trade and the bad rate in the graph 1250 than in the graph 1240.Therefore, the leveled finance attribute shown in graph 1250demonstrates a greater correlation to credit risk than the unleveledfinance attribute shown in graph 1240.

As set forth above the leveled attribute may be used in one or moremodels wherein the model is applied to a set of data relating to one ormore customers. In some embodiments, the models use a plurality ofattributes to predict a characteristic, such as, for example, the risklevel for one or more customers or the likelihood of bankruptcy for theone or more customers. FIG. 13 illustrates sample embodiments of a modelthat can be used to test an attribute. In FIG. 13, one version of themodel used the unleveled finance attribute and another version of themodel used the leveled finance attribute. Graph 1300 illustrates thetesting of the finance attribute on Model KS (in one embodiment, modeledafter Kolmogorov-Smirnov). KS is the maximum point difference betweenthe cumulative distribution of “goods” and the cumulative distributionof “bads.” In one embodiment, the “goods” represent data sample with lowdefault risk/good repayment history while “bads” represent data samplewith high default risk/poor repayment history. In one embodiment, thedifference scale is shown along the Y-axis of graph 1300. In someembodiments, a high KS is desirable because it indicates a largeseparation between the good rate and the bad rate. Graph 1300 shows howthe first Model KS graph measures alternative characteristics and checkhow the Model KS changes as the characteristics change.

The graph 1300 show that for B1 and B3, the model was better for theleveled attribute and slightly worse for B2. Graph 1310 illustratesanother testing of the finance attribute using a model that predicts thebad rate in the worst 5% of a population. The numbers in FIGS. 12A-Creflect the sample population while the model shown in graph 1310 takesthe worst 5% of the score range. By having a higher bad rate with theleveled definitions across the spectrum, this indicates that the modelis pushing more bad to the bottom, which is an indication of a betterperforming model. As shown in the graph 1310, for B1 and B2, the modelwas better using the leveled attribute and just slightly worse for usingB3. In one embodiment, an attribute can be further leveled until thedifference between the non-leveled attribute and the leveled attributeexceeds a predetermined threshold for one or more of the data sources.

Although the foregoing invention has been described in terms of certainembodiments, other embodiments will be apparent to those of ordinaryskill in the art from the disclosure herein. Moreover, the describedembodiments have been presented by way of example only, and are notintended to limit the scope of the inventions. Indeed, the novel methodsand systems described herein may be embodied in a variety of other formswithout departing from the spirit thereof. Accordingly, othercombinations, omissions, substitutions and modifications will beapparent to the skilled artisan in view of the disclosure herein.

1-21. (canceled)
 22. A computer implemented method for generating afinance attribute from raw tradeline data from a plurality of creditdata sources, the method comprising: retrieving raw tradeline data fromeach of a plurality of credit data sources; retrieving industry codedata related to each of the plurality of credit data sources;determining one or more tradeline characteristics to select as levelingcharacteristics; and generating a leveled finance attribute using theselected leveling characteristics.
 23. The computer implemented methodof claim 22, wherein determining one or more tradeline characteristicsas leveling characteristics comprises: designating a plurality of lowestcommon denominators from the industry code data related to each of theplurality of credit data sources as selected leveling characteristics;leveling the raw tradeline data from each of the plurality of creditdata sources to generate leveled tradeline data using the selectedleveling characteristics; measuring a correlation among the leveledtradeline data and the raw tradeline data; determining whether thecorrelation meets at least one pre-defined threshold; adjusting theselected leveling characteristics if the correlation fails to meet theat least one pre-defined threshold; and repeating said leveling,measuring, determining, and adjusting until the selected levelingcharacteristics generate a correlation that meets the at least onepre-defined threshold.
 24. The computer implemented method of claim 23further comprising: excluding extraneous tradeline data from the leveledtradeline data.
 25. The computer implemented method of claim 23 furthercomprising: measuring a difference between a non-leveled financeattribute and the leveled finance attribute; determining whether thedifference meets at least one pre-defined threshold.
 26. The computerimplemented method of claim 22, wherein the plurality of credit datasources include a plurality of credit bureaus.
 27. The computerimplemented method of claim 22, wherein the industry code data includesindustry identifiers.
 28. The computer implemented method of claim 22,wherein the tradeline leveling characteristics relate to finance data.29. The computer implemented method of claim 22 further comprisingapplying the finance attribute to individual finance data.
 30. A storagemedium having a computer program stored thereon for causing a suitableprogrammed system to process computer-program code by performing thecomputer implemented method of claim 22 when such program is executed onthe system.
 31. A computing system comprising: a communications moduleconfigured to receive raw tradeline data related to a plurality ofcredit data sources and to receive industry code data related to each ofthe plurality of credit data sources; a finance attribute generationmodule configured to receive raw tradeline data from each of theplurality of credit data sources via the communications module, receiveindustry code data related to each of the plurality of credit datasources via the communications module; determine one or more tradelinecharacteristics to select as leveling characteristics, and generate afinance attribute using the selected leveling characteristics; and aprocessor module configured to execute the finance attribute generationmodule.
 32. The computing system of claim 31 wherein the financeattribute generation module is further configured to determine one ormore tradeline characteristics as leveling characteristics by:designating a plurality of lowest common denominators from the industrycode data related to each of the plurality of credit data sources asselected leveling characteristics; leveling the raw tradeline data fromeach of the plurality of credit data sources to generate leveledtradeline data using the selected leveling characteristics; measuring acorrelation among the leveled tradeline data and the raw tradeline data;determining whether the correlation meets at least one pre-definedthreshold; adjusting the selected leveling characteristics if thecorrelation fails to meet the at least one pre-defined threshold; andrepeating said leveling, excluding, measuring, determining, andadjusting until the selected leveling characteristics generate acorrelation that meets the at least one pre-defined threshold.
 33. Thecomputing system of claim 32, wherein adjusting the selected levelingcharacteristic comprises at least one of narrowing the selected levelingcharacteristics for at least one of the credit data sources to adifferent subset of industry code data or including additional industrycode data for at least one of the credit data sources not included inthe lowest common denominators in the selected leveling characteristics.34. The computing system of claim 32 wherein the finance attributegeneration module is further configured to determine one or moretradeline characteristics as leveling characteristics by: excludingextraneous tradeline data from the leveled tradeline data.
 35. Thecomputing system of claim 32 wherein the finance attribute generationmodule is further configured to determine one or more tradelinecharacteristics as leveling characteristics by: measuring a differencebetween a non-leveled finance attribute and the leveled financeattribute; determining whether the difference meets at least onepre-defined threshold.
 36. The computing system of claim 31 wherein theplurality of credit data sources include a credit bureau.
 37. Thecomputing system of claim 31 wherein the industry code data includesindustry identifiers.
 38. The computing system of claim 31 wherein thetradeline leveling characteristics relate to finance data.
 39. Thecomputing system of claim 31 wherein the finance attribute generationmodule is further configured to apply the finance attribute toindividual finance data.